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ABSTRACT 

This  report  describes  some  of  the  functions  that  individuals  within  the  Tactical  Air  Operations 
Centre  (TAOC)  may  perform,  and  proposes  software  tools  that  may  assist  with  battle 
management  duties.  In  particular,  we  focus  on  the  NORTHROC  Operations  Officer  (NOPSO). 
We  begin  with  a  brief  description  of  the  TAOC  environment  and  the  duties  of  the  NOPSO, 
followed  by  observations  and  interviews  from  Air  Exercise  Pitch  Black  2000.  The  results  of  the 
analysis  provide  a  basis  for  proposing  various  tools,  which  are  described  in  terms  of  their 
function,  advantages,  disadvantages,  feasibility  and  research  interest.  Finally,  a  particular  set 
of  tools  is  suggested  for  further  development. 
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Executive  Summary 

The  design  of  software  should  support  the  tasks  of  the  user.  This  report  is  the 
beginning  of  an  effort  to  document  the  tasks  of  the  NORTHROC  Operations  Officer 
(NOPSO),  and  identify  those  that  can  be  assisted  by  software  design. 

The  document  is  structured  in  the  following  manner.  Firstly,  there  is  a  brief  description 
of  the  NOPSO's  environment  in  both  an  organisational  and  a  physical  sense. 
Subsequently,  there  is  reference  to  domain  familiarisation  and  two  previous  analyses, 
one  using  IDEFO  and  the  other  using  Cognitive  Task  Analysis  (CTA).  Existing  software 
support  is  provided  by  the  Phoenix  Display  System  and  occasional  use  of  the  Asset 
Visualisation  Tool.  Voice  communication  is  also  supported.  Further  analysis  was  based 
upon  additional  data  sources  such  as  interviews,  exercise  observations,  and  verbal 
protocols  with  subject  matter  experts. 

From  this  work  a  number  of  possible  software  tools  are  suggested.  The  first  four  tools 
are  aimed  at  assisting  calculations  over  a  very  short  timeframe,  that  is,  the  very  tactical. 
These  tools  include  an  estimation  of  aircraft  travel  when  lost  from  radar,  an  estimation 
of  enemy  fuel/ remaining  range,  a  time-to-target  display,  and  an  estimation  of  the  latest 
possible  scramble  time  for  aircraft.  The  next  three  tools  are  to  assist  in  assessing  a 
possible  threat,  and  they  might  be  classed  as  external  memory  aids.  They  include  a 
multi-attribute  track  history,  alerts  when  aircraft  deviate  from  expected  behaviour  and 
a  searchable  emitter  library  to  help  identify  aircraft.  The  final  tool  suggested  is  a  long¬ 
term  asset  schedular  for  radar  and  aircraft  maintenance  and  relocation  that  would  be  of 
assistance  to  the  Director  of  Operations  and  the  NOPSO. 

Each  tool  proposal  is  presented  with  a  brief  description  of  the  problem  and  the  aim  of 
the  tool  to  address  it,  the  identified  end-users  of  the  tool,  and  a  brief  discussion  of  the 
benefits  to  the  user.  Some  ideas  for  implementing  the  concept  are  given,  together  with 
the  initial  impressions  of  the  data  required  for  implementation.  A  discussion  of  the 
technical  "do-ability"  of  implementing  the  proposed  tool  follows,  listing  the  pros,  cons, 
effort  required,  and  opportunities  to  leverage  off  other  work  packages.  Lastly,  a 
discussion  of  the  appropriateness  of  implementing  a  demonstrator  of  the  proposed  tool 
(based  on  the  scientific  contribution,  task  relevance  and  user  benefits)  is  given. 

The  recommendations  detailed  are  all  achievable  with  current  technology.  A  system, 
with  a  live  feed,  based  on  these  recommendations  could  operate  in  a  stand-alone  mode, 
without  having  to  be  installed  on  existing  hardware,  and  consequently,  without 
impacting  on  current  operations.  Finally,  we  assign  a  priority  to  each  concept,  based  on 
the  identified  need  and  the  assessed  feasibility  of  implementation.  We  intend  to 
explore  the  concepts  further  in  terms  of  requirements  analysis,  design,  and 
implementation. 
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1.  Overview 

This  report  describes  a  number  of  functions  that  individual  air  defenders  within  the 
Tactical  Air  Operations  Centre  (TAOC)  perform,  and  proposes  software  tools  that  may 
assist  with  battle  management  duties,  with  particular  focus  on  those  of  the  Northern 
Regions  Operations  Centre  Operations  Officer  (NOPSO).  The  report  begins  with  a  brief 
description  of  the  Tactical  Air  Operations  Centre  environment  and  the  duties  of  the 
NOPSO  to  orient  the  reader.  Observations  and  interviews  from  Air  Exercise  Pitch  Black 
2000  are  described,  with  the  resulting  analysis  providing  a  basis  for  proposing  various 
tools.  The  proposed  software  tools  are  described  in  terms  of  their  function,  advantages, 
disadvantages,  feasibility,  and  research  interest.  Finally,  as  the  first  part  of  a  more 
formal  requirements  analysis,  a  particular  set  of  tools  is  suggested  for  further 
development. 


2.  The  NOPSO's  environment 


The  Joint  Force  Air  Operations  Centre  (JFAOC)  issues  both  positive  and  procedural 
directives  to  ensure  airspace  control.  In  addition,  liaison,  intelligence,  operations  and 
planning  functions  contribute  towards  the  execution  of  air  operations.  A  brief 
description  follows. 

Within  the  Royal  Australian  Air  Force  (RAAF),  the  Surveillance  and  Control  Group 
(SCG)  is  one  of  the  Force  Element  groups  forming  Air  Command,  the  operational 
section  of  the  RAAF.  The  SCG  is  responsible  for  developing  a  comprehensive  air 
surveillance  picture,  particularly  over  our  northern  approaches,  to  enable  effective 
Defensive  Counter  Air  campaigns.  SCG  comprises  a  number  of  units  within  41  Wing 
(41WG):  the  Surveillance  and  Control  Training  Unit  (SACTU);  No.  3  Control  and 
Reporting  Unit  (3CRU)  and  No.  2  Control  and  Reporting  Unit  (2CRU);  No.  114  Mobile 
Control  and  Reporting  Unit  (114  MCRU);  No.  1  Radar  Surveillance  Unit  (1RSU);  and 
RAAF  Air  Traffic  Control  flights. 

2CRU  is  located  at  Lee  Point  in  Darwin  and  consists  of  the  Northern  Command  Centre 
(NCC),  the  Regional  Correlation  Centre  (RCC)  and  the  TAOC,  which  together  form  the 
Northern  Regions  Command  Centre. 

The  RCC  provides  the  Wide  Area  Surveillance  Picture  (WASP).  This  centre  provides  an 
amalgam  of  short  and  long  range  radars,  intelligence  and  civilian  traffic  information. 
The  NCC  provides  the  interface  between  the  operational  influence  of  the  JFAOC  and 
the  TAOC.  The  TAOC  provides  the  interface  between  the  NCC  and  the  ADF  response 
elements. 
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The  Director  of  NORTHROC  Operations  (DNO)  resides  in  the  NCC,  which  contains  a 
number  of  sub-agencies  that  provide  the  DNO  with  advice.  These  agencies  provide 
advice  and  guidance  on  intelligence,  airspace  coordination,  law,  logistics, 
communications,  sensor,  and  systems  issues. 

The  TAOC  is  headed  by  the  NOPSO,  who  functions  within  the  TAOC  to  provide 
airspace  management,  tactical  direction,  and  fighter  control  support.  Tools  available  to 
the  NOPSO  for  battle  management  include: 

■  the  Phoenix  Display  System  (for  radar  and  track  information); 

•  TDRAP  (for  additional  visualisation  of  the  air  picture); 

■  an  Air  Defence  Operations  Computer  System  (ADOCS)  computer  terminal; 

■  the  Asset  Visualisation  Tool  (AVT),  which  is  built  around  a  Gantt  chart  for 
visualising  asset  readiness  and  usage;  and 

■  phone  and  radio  lines. 

The  Air  Defence  Plan  and  Air  Tasking  Order,  refinements  of  the  directives  from  the 
JFAOC,  provide  the  outlines  and  constraints  for  the  TAOC's  activities. 


3.  NOPSO  Analysis 


3.1  Previous  work 

The  NOPSO  performs  a  number  of  functions  in  the  TAOC.  Those  functions  pertain  to 
both  the  complexities  of  leading  a  team  and  air  defence.  For  simplicity  we  chose  to 
focus  on  those  activities  that  directly  supported  air  defence. 

In  support  of  previous  work  to  design  a  software  tool  to  support  the  NOPSO,  several 
studies  were  completed.  Pitch  Black  96  facilitated  initial  domain  familiarisation  for  the 
report  by  McCloughry  et  al.  (1997)  which  describes  the  layout  of  the  NCC  and  the 
TAOC  (then  known  respectively  as  the  Sector  Air  Defence  Operations  Centre,  or 
SADOC,  and  the  Command  &  Control  Centre,  or  CCC),  and  the  staff  roles  and 
functions  within  the  TAOC.  In  addition,  IDEFO  modelling  was  carried  out  to  provide 
analysis  for  the  development  of  the  AVT.  This  modelling  had  identified  the  main 
inputs,  outputs,  and  activities  of  a  NOPSO  but  mentioned  some  difficulty  in 
sufficiently  constraining  the  NOPSO's  job  to  fit  the  IDEFO  framework  (Taplin  et  al., 
P-29). 

The  work  described  above  provided  data  for  domain  familiarisation  to  inform  the 
construction  of  a  more  detailed  executable  cognitive  model  of  the  NOPSO  (Mitchard  et 
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al,  2000).  Further  knowledge  acquisition  sessions  provided  opportunities  to  gather 
interview,  observational,  and  verbal  protocol  data.  Cognitive  Task  Analysis  (CTA) 
techniques  were  applied  to  verbal  protocols  and  interview  data,  enabling  the 
identification  of  goal  structures,  and  the  procedural,  perceptual,  and  declarative 
knowledge  needed  to  perform  the  NOPSO's  task. 

As  it  was  difficult  to  define  the  method  of  accomplishing  the  NOPSO's  goal  (namely, 
"to  defend  the  airspace"),  sub-goals  were  used  to  regulate  task  accomplishment  (Hoc, 
1988).  That  is,  when  the  top-level  goal  cannot  be  defined  precisely,  the  goal  can  be 
achieved  through  an  ongoing  process  of  satisfying  sub-goals  that  are  not  necessarily  in 
any  predetermined  order. 

The  NOPSO  model  constructed  was  based  on  the  execution  of  four  sub-goals  that  were 
identified: 

1.  The  maintenance  of  situation  awareness; 

2.  The  prioritisation  of  threats; 

3.  The  protection  of  all  assets  by  the  maintenance  of  the  appropriate  alert  status;  and 

4.  The  management  of  fuel  and  weapons  of  friendly  aircraft. 

ADF  documentation  lists  additional  duties  of  the  NOPSO  as  Advising  the  DNO  of  the 
current  situation,  and  overseeing  the  TAOC  operations  and  the  functions  performed  by 
the  Tactical  Director  (TACDIR),  Air  Controller  (AIRCON)  and  Regional  Surveillance 
Officer  (RSO). 


3.2  Existing  tool  support 

The  main  geospatial  display  of  the  TAOC  is  provided  by  the  Phoenix  Display  System 
(PDS,  or  generally,  "Phoenix").  All  personnel  within  the  TAOC  receive  their  own 
Phoenix  picture  on  the  screen  of  a  personal  computer  running  the  Windows  NT 
operating  system.  This  picture  is  an  amalgam  of  airborne  tracks  from  various  radar 
sources,  augmented  by  the  staff  of  the  RCC  with  intelligence  data  that  enables  the 
resolution  of  inconsistencies.  The  map  scale  of  each  display  can  be  adjusted  by 
individual  users  to  focus  on  particular  geographic  regions,  and  filters  can  be  applied  to 
display  only  track-types  of  interest.  Other  staff  can  add  information  about  the  fuel 
states  and  weapon  loads  of  friendly  aircraft  in  the  air;  however,  in  practice  this 
function  is  not  often  used. 

TDRAP  is  a  DSTO-developed  concept  demonstrator  that  has  been  placed  in  the  NCC  to 
provide  an  additional  geospatial  view  of  the  recognised  air  picture.  A  feed  of  TDRAP 
data  can  be  made  available  to  a  terminal  in  the  TAOC  as  required.  It  provides  an 
alternative  track  fusion /resolution  to  that  performed  by  the  RCC,  so  that  the  user  is 
able  to  consult  this  system  if  a  track  produced  by  the  main  tracking  system  (the 
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MV 15000)  disappears  from  their  Phoenix  display  and  they  wish  to  maintain  situation 
awareness. 

The  Air  Defence  Operations  Computer  System  (ADOCS)  receives  a  feed  of  data  from 
the  main  tracking  computer  and  is  capable  of  producing  an  uncluttered  recognised  air 
picture  to  users  with  graphical  workstations  as  well  as  providing  tabular  information 
to  users  with  simple  text  terminals.  The  function  of  its  geospatial  display  has  been 
superseded  by  Phoenix,  however,  its  simpler,  tabular  form  provides  additional 
information  such  as  aircraft  mission  allocation,  alert  status,  and  requested  and  actual 
scramble  times.  This  information  can  be  updated  at  individual  squadrons  and  viewed 
in  the  TAOC. 

The  AVT,  as  previously  mentioned,  is  a  DSTO-developed  concept  demonstrator  that 
grew  out  of  observations  made  at  Pitch  Black  96.  The  air  defenders  observed  had  a 
good  appreciation  of  the  geospatial  information  relating  to  their  airborne  assets,  but 
had  to  resort  to  various  external  memory  aids  (ranging  from  shared  magnetic 
whiteboards  to  personal  notes)  to  better  manage  the  current  status  of  their  ground- 
based  and  airborne  assets.  Some  of  this  information  was  captured  by  ADOCS, 
however,  users  had  to  drill  down  through  various  levels  of  menus  in  order  to  find  the 
data  they  required.  Additional  information,  such  as  fuel  and  weapon  states  was  not 
available,  except  to  those  who  made  requests  via  individual  fighter  controllers  (FCs). 
The  graphical  Gantt  chart  visualisation  of  the  AVT  provided  shared  data  and 
automated  calculations  to  various  users  in  the  TAOC,  better  enabling  them  to 
conceptualise  a  large  amount  of  temporal  information  at  a  glance. 

Voice  communications  outside  2CRU  are  enabled  via  secure  telephone  and  radio 
networks.  Instructions  and  information  from  other  NCC  and  TAOC  staff  are 
communicated  via  intercoms.  The  discussions  are  mainly  liaison  with  other  units  such 
as  the  civilian  air  traffic  control  system,  intelligence  sources.  Army  and  Navy  units,  and 
various  support  units.  The  NOPSO  also  communicates  regularly  with  the  DNO,  who  is 
in  contact  with  Headquarters  Air  Command  (HQAC),  in  order  that  information  is 
relayed  upwards  to  senior  military  decision  makers,  and  to  keep  up  to  date  with  any 
variation  of  intent  resulting  from  wider  military  or  political  considerations. 


3.3  Further  analysis  of  the  NOPSO's  task 


3.3.1  Data  collection 

The  additional  data  sources  for  this  document  were  interviews,  exercise  observations, 
and  verbal  protocols  with  subject  matter  experts  (SMEs). 
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3.3. 2.2  Repertory  grid  interviews 

In  an  effort  to  understand  the  physical  characteristics  of  aircraft  that  contributed  to 
threat  assessment,  repertory  grids,  a  psychometric  technique,  were  applied  with  RAAF 
personnel.  Repertory  Grid  technique  (Easterby-Smith,  1981)  offers  a  means  of  eliciting 
some  ordering  of  the  attributes  of  members  within  a  category.  In  this  instance,  the 
category  was  aircraft,  and  the  technique  was  used  to  direct  the  interview  to  identify  the 
relationship  between  threat  level  and  physical  attributes  of  the  aircraft.  The  verbal 
protocols  of  the  repertory  grid  process  provided  additional  data. 

3.3. 2. 2  Exercise  observations  and  interviews 

Pitch  Black  2000  was  a  joint  Air  Defence  exercise  carried  out  in  the  Tindal/Darwin  area 
of  the  Northern  Territory  during  July  2000.  Two  wings  were  created  for  the  exercise, 
95WG,  designated  Offensive  Counter  Air  (OCA),  and  96WG,  its  counterpart.  Defensive 
Counter  Air  (DCA).  Aircrew  and  aircraft  of  a  number  of  countries  took  part,  and  the 
resources  of  SCG  were  divided  between  the  two  wings  named  above.  The  TAOC,  and 
consequently  the  NOPSO,  were  charged  with  defending  the  exercise  airspace  with  the 
assets  allocated  to  96WG. 

Voice  recordings  of  the  NOPSOs  were  made  during  exercise  periods,  together  with  a 
lesser  number  of  physical  observations.  Verbal  protocols  were  obtained  from  former 
NOPSOs  during  other  exercise  periods.  These  people  were  SMEs  who  had  previously 
performed  in  this  role  and  were  able  to  observe,  infer,  and  comment  on  the  decisions  of 
the  current  NOPSO,  who  would  be  unavailable  for  comment  due  to  their  high 
workload.  As  the  exercise  scenario  did  not  vary  greatly  from  window  to  window,  the 
SMEs  were  familiar  with  the  problem  and  able  to  provide  data  immediately. 


3.3.2  Data  analysis  and  results 

The  repertory  grid  interviews  were  transcribed.  The  repertory  grids  constructed, 
together  with  their  transcriptions,  provided  cues  and  factors  that  were  considered  as 
part  of  the  assessment  of  the  threat  level  of  a  track.  Interviews  and  observations  from 
Pitch  Black  2000  provided  naturalistic  data  that  has  been  analysed  in  a  qualitative 
manner. 
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Cognitive  task  analysis  of  the  threat  assessment  function  performed  by  the  NOPSO 
identified  the  following  tasks  and  sub-tasks: 

1.  Maintain  situation  awareness: 

o  Recognising  new  tracks; 
o  Identifying  tracks;  and 
o  Monitoring  tracks. 

2.  Prioritisation  of  threats: 

o  Assessing  threat  level  of  tracks. 

3.  Protect  assets: 

o  Devising  the  appropriate  response  to  tracks. 

4.  Management  of  fuel  and  weapons  of  friendly  aircraft: 

o  Maintenance  of  the  appropriate  alert  status. 

The  demands  on  the  NOPSO  for  each  of  these  tasks  are  briefly  outlined  below. 

3.3.2.1  Maintain  situation  awareness 

Both  recognising  new  tracks  and  identifying  tracks  is  primarily  the  job  of  the  RCC. 
However  the  NOPSO  revisits  some  tracks  and  consults  with  the  RCC  to  check  the 
consistency  of  the  identification.  Especially  when  some  feature  is  contradictory  to  the 
assigned  identification  the  NOPSO  and  the  RCC  may  have  frequent  voice  consultations 
to  try  to  resolve  the  matter. 

Of  all  the  tasks,  it  could  be  argued  that  monitoring  tracks  is  the  most  difficult  of  the 
various  functions  that  the  NOPSO  carries  out.  The  difficulty  arises  because  of  the  many 
demands  on  the  NOPSO's  attention,  the  high  load  on  memory,  and  the  clutter  of  the 
geographical  representation  on  the  screen.  However,  it  is  a  crucial  task,  as  monitoring 
tracks  enables  the  construction  of  a  track  history  that  assists  in  determining  intent. 

A  functional  level  analysis  of  these  sub- tasks  led  to  the  suggestion  that  tools  of  possible 
use  would  include  a  multi-dimensional  track  history  and  an  estimation  of  aircraft 
travel  when  lost  from  radar. 

3.32.2  Prioritisation  of  threats 

The  prioritisation  of  individual  threats  makes  the  task  of  situation  assessment  more 
tractable.  The  complex  problem  of  assessing  intent  does  not  rely  only  on  physical  and 
temporal  characteristics  alone,  as  there  is  no  clear  demarcation  between  civil  and  other 
aircraft  on  radar  revealed  characteristics  alone.  Recognition  of  regular  civil  traffic 
removes  a  large  number  of  aircraft  from  consideration;  however,  variance  from  normal 
flight  times  can  make  the  task  of  correct  identification  more  difficult.  It  is  expected  that 
information  from  The  Australian  Advanced  Air  Traffic  System  (TAAATS)  may 
alleviate  this  concern. 


6 


DSTO-CR-0310 


More  importantly  the  geospatial  display  is  far  from  optimal  in  assisting  the  NOPSO  to 
order  the  estimated  arrival  times  of  threats  as  the  crucial  information  is  not  distance 
but  time-to-target.  As  mentioned  above,  to  augment  the  information  on  the  geospatial 
display  the  NOPSO  relies  on  information  from  the  RCC.  The  importance  of 
considering  intelligence  information  when  engaged  in  assessing  the  threat  level  posed 
by  both  individual  and  formatted  aircraft  cannot  be  overstated.  Currently,  the  task  of 
integrating  intelligence  information  is  purely  cognitive,  as  there  are  difficulties  in  both 
transmitting  and  displaying  this  type  of  information. 

For  this  sub-task,  a  functional  level  analysis  indicated  possible  tools  including  a  time- 
to-target  display,  alerts  when  aircraft  deviate  from  expected  behaviour,  an  estimation 
of  enemy  fuel/remaining  range,  and  a  searchable  emitter  library  to  help  identify 
aircraft. 

3.3.2. 3  Protect  assets 

The  first  planning  activity  that  the  NOPSO  engages  in  is  the  setting  of  a  posture.  In 
brief,  a  posture  is  an  arrangement  of  ground  and  airborne  radars  and  a  number  of 
aircraft  at  various  states  of  readiness.  This  posture  is  based  on  the  possibilities  offered 
from  the  combination  of  intelligence  on  the  enemy  and  Australian  Defence  Force 
(ADF)  information. 

Devising  an  appropriate  response  to  threats  is  the  second  part  of  the  planning  that  the 
NOPSO  must  engage  in.  The  first  part  of  the  task  is  to  determine  whether  a  track 
should  be  engaged  or  not.  If  the  assessment  is  that  a  track  should  be  engaged  then  the 
NOPSO  determines  the  appropriate  time  and  location  of  the  engagement.  Once  it  is 
determined  that  the  threat  level  of  a  track  necessitates  a  response.  Standard  Operating 
Procedures  (SOPs)  and  Rules  Of  Engagement  (ROEs)  constrain  the  actions  that  may  be 
considered. 

Testing  of  the  NOPSO  model  indicated  that  when  a  threat  is  posed  by  fighter  aircraft 
alone,  that  the  presence  of  strike  aircraft  does  not  require  higher  alert  states  (Mitchard 
et  al.,  2000).  Similarly,  observational  data  indicated  that  if  the  NOSPO  had  insufficient 
information  about  approaching  tracks  then  they  tended  to  assume  the  worst  and 
prepare  for  self-defence. 

A  functional  level  analysis  of  this  sub-task  led  to  a  suggested  tool  for  estimating  the 
latest  possible  scramble  time  for  aircraft. 

3.3.2A  Management  of  fuel  and  weapons  of  friendly  aircraft 

In  the  process  of  maintaining  appropriate  alert  status  or  mounting  an  effective  defence, 
aircraft  consume  both  weapons  and  fuel.  Constraints  such  as  fuel  consumption  and 
limited  weapons  affect  the  manner  in  which  the  NOPSO  can  change  the  air  defence 
picture.  Therefore,  careful  management  of  aircraft  usage  is  essential. 
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An  aircraft's  fuel  and  weapons  status  determine  the  length  of  time  it  can  remain 
airborne  and  whether  the  aircraft  will  be  equipped  to  engage  the  opposition.  An 
aircraft  that  has  sufficient  weapons,  which  doesn't  require  maintenance,  and  whose 
pilot  is  not  fatigued,  may  be  refuelled  from  an  airborne  tanker,  otherwise  it  must  return 
to  an  airfield  and  wait  for  an  average  forty  minutes  (up  to  an  hour)  to  elapse  before  it 
can  be  ready  to  fly  again.  As  the  NOPSO's  planning  cycle  includes  not  only  the 
preparation  and  scramble  times  of  aircraft,  but  the  airborne,  turnaround  and  release 
times  as  well,  the  planning  cycle  for  this  task  is  approximately  4  to  12  hours. 

Ideally,  performance  of  this  task  will  ensure  the  absolute  optimisation  of  finite 
resources  and  prevent  the  NOPSO  from  creating  a  state  where  lack  of  maintenance 
fails  to  provide  the  necessary  assets  to  deal  with  enemy  aircraft.  The  Asset 
Visualisation  Tool  reduces  the  NOPSO's  mental  load  assisting  in  the  management  of 
aircraft  usage  over  the  course  of  a  day.  However  the  AVT  does  not  address  other 
issues  and  consequently  a  functional  analysis  of  this  sub-task  suggested  a  long-term 
asset  schedular  for  radar  and  aircraft  maintenance  and  relocation. 


4.  Possible  Software  Tools 


4.1  Tool  concepts 

The  purpose  of  this  section  is  to  present  functional  tool  concepts  and  arguments  that 
contribute  towards  an  evaluation  of  each  concept.  We  consider  issues  such  as  the 
resources  necessary,  feasibility  of  implementation  and  user  benefits,  and  prioritise  the 
tool  concepts  on  these  bases.  Each  tool  concept  is  presented  with  the  following  fields: 

Title  The  tool's  title. 

Problem  A  brief  description  of  the  problem  and  the  aim  of  the  tool  to 

address  it. 

User(s)  The  identified  end-users  of  the  tool. 

Impact  A  listing  of  the  benefits  to  the  user  and  possible  measures  of 

effectiveness. 

Implementation  Some  initial  ideas  for  implementing  the  concept. 

Information  A  preliminary  list  of  the  data  required  for  implementation. 
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Feasibility  A  discussion  of  the  technical  "do-ability"  of  implementing  the 

proposed  tool,  listing  the  pros,  cons,  effort  required,  and 
opportunities  to  leverage  off  other  work  packages. 

Desirability  A  discussion  of  the  appropriateness  of  implementing  a 

demonstrator  of  the  proposed  tool,  based  on  the  scientific 
contribution,  task  relevance,  and  user  benefits. 

Although  elements  of  the  graphical  user  interface  or  methods  of  interaction  might  be 
alluded  to,  it  is  the  functional  description  that  is  of  primary  focus.  Subsequent  work  will 
flesh  out  the  "look  and  feel"  of  the  tools  nominated  for  implementation  as  part  of 
thorough  requirements  determination  and  design  phases. 


4.1.1  An  estimation  of  aircraft  travel  when  lost  from  radar 
Problem 

When  a  track  is  lost  from  radar,  either  due  to  a  system  malfunction  or  because  an 
aircraft  has  manoeuvred  so  as  to  be  non-detectable,  the  track  may  cease  to  move  or 
may  disappear  from  radar  screens.  This  results  in  a  period  of  uncertainty  and  poor 
situation  awareness.  A  tool  is  required  which  would  display  interim  track  positions 
until  the  normal  condition  is  restored. 

User(s) 

■  NOPSO,  TACDIR,  FC 

Impact 

A  graphical  representation  of  a  track  no  longer  updated  by  radar  could  enable  the 
NOPSO  to  more  fully  maintain  situation  awareness  by  reducing  the  load  on  memory. 

The  representation  of  aircraft  travel  may  be  based  on  the  last  known  heading  and 
speed  of  a  track,  however  this  may  have  negative  results  if  the  NOPSO  does  not 
consider  the  implications  of  alternate  directions  of  travel.  To  add  an  element  of 
ambiguity,  the  aircraft's  travel  may  be  represented  with  an  expanding  "range  ring", 
but  this  may  supply  no  useful  constraints — an  expanding  ring  on  its  own  might  only 
provide  vague  or  worthless  information  to  the  user — and  merely  clutter  the  display. 

The  heuristic  might  attempt  to  update  the  potential  track  position  (with  its  element  of 
uncertainty)  until  the  link  to  the  actual  track  is  restored  or  an  update  on  the  current 
position  is  provided  by  communications  with  pilots.  However,  a  constrained 
representation  (using  expanding  wedges,  for  example)  might  instil  a  level  of  trust  in 
information  that  might  not  be  accurate. 
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This  tool  would  provide  a  common  picture  for  all  users  and  greatly  help  in 
maintaining  situation  awareness,  however,  it  might  not  see  frequent  use,  as  its  benefit 
would  only  be  evident  during  track  loss  or  freeze. 

Implementation 

The  use  of  "expanding  rings"  is  an  approach  used  in  other  systems,  and  described  in 
the  literature.  The  heuristics  can  range  from  the  simple  (where  the  ring  is  expanded  at 
the  same  rate  as  the  last  known  speed)  to  the  very  complex.  An  indication  of  the 
possible  position  of  the  aircraft  might  be  shown  by  a  shaded  wedge  within  the  range 
ring,  based  on  information  such  as  the  last  known  heading  and  speed,  and  allowing  for 
a  certain  amount  of  variation. 

On  tracks  being  "lost",  a  snapshot  of  the  last  known  positions  might  be  shown  using 
specially  marked  track  symbols.  The  user  might  choose  to  convert  a  small  number  of 
these  symbols  to  expanding  rings  (as  opposed  to  all  of  them  instantly  expanding)  in  an 
attempt  to  reduce  clutter. 

Information 

The  information  required  to  implement  this  tool  is  available  as  Phoenix  track  updates, 
including  last  known  position,  heading,  and  speed.  Logging  of  track  updates  would 
have  to  be  performed  to  determine  those  tracks  that  are  considered  "lost"  (that  is,  have 
not  received  an  update  for  a  given  period  of  time  or  number  of  update  cycles). 
Additional  information  may  be  required,  as  determined  by  the  heuristics  described  in 
the  literature. 

Feasibility 
■  Medium: 

Barring  any  great  complexity  suggested  by  the  literature,  the  algorithm  and 
visualisation  for  this  tool  seem  achievable. 

Desirability 

>  High: 

The  proposed  tool  fits  well  within  the  research  aims  of  the  task. 


4.1.2  An  estimation  of  enemy  fuel/remaining  range 
Problem 

An  appreciation  of  the  estimated  remaining  flying  time  for  enemy  aircraft  is  important 
for  commanders  to  gauge  the  enemy's  ability  to  sustain  their  effort,  and  to  be  able  to 
discount  tracks  that  pose  a  minimal  threat  because  of  the  length  of  their  outward 
journey.  Well-trained  commanders  attempt  to  use  "ball-park"  figures  for  the  remaining 
flying  time  of  enemy  aircraft  by  making  "mental  notes"  of  when  they  first  appeared. 
This  places  an  unnecessary  workload  on  the  commander.  A  tool  is  proposed  which 
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attempts  to  more-accurately  calculate  remaining  flying  time  and  display  the  threat's 
remaining  range. 

User(s) 

-  NOPSO,  TACDIR 
Impact 

The  tool  addresses  a  known  task  that  the  commander  attempts  to  solve:  to  evaluate  the 
threat  posed  by  enemy  aircraft  and  to  adequately  plan  the  defensive  response.  It  is 
hypothesised  that  if  the  tool  was  used,  a  large  reduction  in  mental  workload  could  be 
shown.  It  should  be  noted  that  this  tool  is  reliant  on  accurate  intelligence  information 
about  the  fuel  tanks  fitted  to  aircraft.  This  information  can  change  on  a  daily  basis. 
Information  such  as  aircraft  type  and  initial  fuel  load  may  not  be  available. 
Assumptions  may  need  to  be  made  to  make  this  tool  work,  but  this  might  result  in 
inaccurate  figures  being  presented.  If  this  information  is  trusted,  it  may  lead  to  critical 
errors. 

The  tool  might  also  be  useful  for  friendly  aircraft,  providing  a  more  accurate 
approximation  of  remaining  fuel  for  the  AVT,  for  those  times  between  updates 
provided  by  the  pilots.  A  fuel  model  may  be  more  accurate  than  a  time-based  one,  but 
if  displayed  as  pounds  of  fuel  remaining  this  may  cause  too  strong  a  focus  on  fine  (and 
potentially  incorrect)  details.  The  result  is  probably  best  presented  to  the  commander 
in  broad  terms  of  remaining  flying  time,  for  example,  <  15  minutes,  <  30  minutes,  etc. 

Implementation 

The  tool  might  simply  record  the  time  that  the  track  was  first  detected,  and  assuming  a 
certain  type  and  fuel  configuration,  might  indicate  how  long  the  aircraft  has  been 
airborne  and  how  long  it  might  reasonably  remain  so.  (For  example,  a  rule  of  thumb 
that  is  often  used  is  that  F/A-18  aircraft  have  a  90  minute  flying  time  without  being 
refuelled  midair.)  The  results  obtained  by  this  method  may  be  inaccurate  if  the  tracks 
behave  very  differently  from  the  model  (for  example,  if  one  aircraft  spends  most  of  its 
time  on  CAP  and  another  is  flying  at  intercept  speeds). 

A  preferable  method  would  be  to  assume  that  an  enemy  aircraft  is  fully  tanked  when  it 
is  first  detected,  and  then  maintain  a  history  of  the  aircraft's  speed  (and  possibly 
altitude).  These  could  be  recorded  into  groupings  that  match  the  categories  of  a  fuel 
consumption  library.  A  calculated  value  for  remaining  fuel  could  be  presented  after 
every  track  update.  A  re-calculation  using  the  grouped  data  could  be  performed  when 
new  intelligence  comes  to  hand  that  changes  the  assumptions  regarding  aircraft  type  or 
initial  fuel  load. 

Remaining  fuel  or  flying  time  might  be  shown  as  a  number  somewhere  on  a  display 
(such  as  with  the  track  symbology),  but  essentially  what  the  commander  is  trying  to  do 
is  to  determine  the  remaining  range  of  an  aircraft,  and  the  threat  that  it  poses.  The  use 
of  a  range  ring  around  a  track  is  a  well-used  technique  that  helps  to  show  the  possible 
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extent  of  an  aircraft's  travel,  and  would  be  updated  if  fuel  usage  was  above  or  below 
the  predicted  expenditure. 

Information 

Information  required  for  this  tool  include  aircraft  type  and  initial  fuel  loads  (as 
assumptions  set  by  the  user),  bum  rates  for  specific  aircraft  at  certain  speeds  and 
altitudes  (loaded  by  the  tool  from  a  library  of  preset  values),  and  track  updates 
(including  heading,  height,  speed,  and  position)  from  the  Phoenix  network. 

Feasibility 
■  Medium: 

A  lot  of  assumptions  need  to  be  made  regarding  the  track  being  studied,  though 
barring  any  great  complexity  suggested  by  the  literature,  the  algorithms  and 
visualisation  for  this  tool  seem  achievable.  The  validity  of  the  tool  could  be  tested 
against  recorded  Phoenix  and  AVT  data  for  friendly  aircraft.  (The  aircraft  type  and 
initial  fuel  load  is  known,  and  updates  for  the  remaining  fuel  are  logged.) 

Desirability 
-  High: 

The  proposed  tool  fits  well  within  the  research  aims  of  the  task  and  seems  like  an 
interesting  and  worthwhile  topic  to  research.  The  determination  of  an  enemy  track's 
remaining  range  forms  the  core  of  the  larger  problem  of  threat  assessment  and  battle 
management. 


4.1.3  A  time-to-target  display 
Problem 

Phoenix  users  have  access  to  a  feature  that  allows  them  to  "rubber-band"  a  line 
between  any  two  points  in  space  and  see  the  calculated  distance  and  bearing  displayed 
along  its  length.  It  is  typically  used  by  FCs  to  measure  the  distance  between  two  tracks, 
so  that  pilots  can  be  informed  of  their  target's  position  if  it  is  not  visible  to  them  (due  to 
the  aircraft  radar's  lesser  range  than  that  available  to  the  TAOC).  The  NOPSO  may  use 
this  tool  to  determine  the  distance  of  an  enemy  track  to  an  ADIZ  and  then  estimate  a 
vague  time  it  would  take  to  get  there.  A  new  tool  is  proposed  that  would  allow  a 
permanent  line  to  be  drawn  between  a  track  and  a  fixed  point,  or  between  two  tracks, 
with  a  calculated  time-to-target  value  constantly  updated  alongside  it. 

User(s) 

■  NOPSO,  TACDIR,  FC 

Impact 

Offloading  the  calculation  of  time-to-target  to  the  computer  should  result  in  a 
reduction  in  memory  load  on  the  user.  The  initial  calculation  will  not  only  be  more 
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accurate  than  the  original  estimate  of  the  user,  but  will  remain  accurate  with  each  new 
piece  of  track  data  that  becomes  available. 

The  tool's  only  limitation  would  come  about  because  it  relies  on  radar  information: 
should  an  enemy  aircraft  avoid  being  detected,  the  tool  would  be  of  little  assistance. 

Implementation 

Two  modes  of  operation  are  envisaged:  time  to  a  stationary  point,  and  time  to  a  point 
of  interception  with  another  track.  (The  mode  would  be  determined  by  the  selection  of 
either  one  or  two  tracks.)  As  just  described,  a  permanent  line  would  be  drawn  between 
the  source  and  destination  point/track,  and  the  time-to-target  values  updated 
alongside  it  with  each  new  track  update  that  arrives  for  the  tracks  concerned.  The 
values  shown  might  include  the  time-to-target,  distance,  and  bearing. 

In  the  case  of  calculating  time-to-intercept  between  two  tracks,  two  lines  would  be 
drawn  between  the  tracks  to  indicate  the  current  bearing  of  one,  with  the  calculated 
intercept  vector  of  the  other.  As  can  be  imagined,  as  the  position,  speed,  and  heading  of 
the  two  tracks  changes,  the  calculated  intercept  may  move  around  significantly,  or 
cease  to  be  valid  if  no  intercept  is  going  to  be  possible.  (How  this  latter  case  will  be 
visualised  will  be  left  for  later  user-interface  design.  For  example,  should  the  intercept 
line  not  be  drawn,  or  drawn  short  of  the  other  track's  bearing  line?) 

The  inclusion  of  a  "buffer  zone"  around  a  stationary  point  or  intercept  point  would 
make  an  allowance  for  the  proximity  a  track  had  to  be  to  that  point  to  make  a  kill  with 
a  weapon  it  could  deploy.  This  would  make  most  cases  somewhat  more  realistic,  as  a 
track  does  not  have  to  be  coexistent  in  space  with  another  before  it  can  make  an 
intercept.  The  additional  information  required  (such  as  the  weapon  available  and  its 
characteristics)  may  make  this  extension  to  the  tool  a  little  too  complex  for 
implementation. 

Further  analysis  will  be  required  to  determine  whether  the  calculation  for  time-to- 
target  should  consider  differences  in  altitude.  It  may  matter  little,  because  the  speed 
provided  by  the  track  update  (from  a  radar  detection)  is  based  solely  on  2-dimensional 
latitude/longitude  changes  over  time. 

Information 

The  information  required  for  this  tool  would  be  provided  by  track  updates,  including 
the  latitude  and  longitude,  speed,  and  heading,  of  either  one  or  two  tracks. 

Feasibility 
■  High: 

The  only  data  required  by  this  tool  is  available  via  track  updates,  and  the  calculations 
that  need  to  be  performed  should  be  relatively  simple.  The  larger  effort  will  be  that  of 
providing  a  suitable,  workable  visualisation. 
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Desirability 
•  High: 

This  tool  would  have  a  number  of  immediate  uses  for  various  staff  of  the  TAOC.  It 
could  be  used  to  calculate  times  for  intercepts  between  two  aircraft,  or  the  time  for  an 
enemy  aircraft  to  reach  a  ground-based  asset  or  a  geospatial  region  (such  as  an  ADIZ). 
Similarly  it  could  be  used  for  friendly  assets  to  determine  the  time  to  reach  a  CAP,  or 
the  time  for  distant,  friendly  aircraft  to  merge  in  the  air  for  the  creation  of  a  new  flight. 

These  examples  suggest  that  the  ability  to  have  multiple  instances  of  this  tool,  on¬ 
screen  at  the  same  time,  will  be  highly  desirable. 

Computationally,  aspects  of  this  tool  would  provide  a  core  for  Tool  4.1.4  ("Estimation 
of  the  latest  possible  scramble  time  for  aircraft"). 


4.1.4  An  estimation  of  the  latest  possible  scramble  time  for  aircraft 
Problem 

The  management  of  the  optimal  defensive  posture  is  crucial  for  successful  defence. 
Although  the  principle  of  "meeting  force  with  (equal  or  greater)  force"  will  be  the 
objective  of  the  NOPSO,  they  will  also  be  mindful  of  conserving  the  resources  at  hand 
and  not  committing  forces  unnecessarily  or  too  early  to  a  fight.  Currently,  NOPSOs 
estimate  the  latest  possible  scramble  time  for  fighter  aircraft  using  the  distance-to- 
target  of  the  approaching  enemy  and  heuristics  developed  through  experience.  A  tool 
that  supports  these  mental  calculations  may  enable  more  efficient  use  of  assets. 

User(s) 

■  NOPSO,  TACDIR 
Impact 

This  tool  proposes  a  slight  twist  on  the  functionality  provided  by  the  Time-To-Target 
tool  (4.1.3),  in  that,  rather  than  calculating  the  location  for  an  intercept  given  a  variable 
speed,  this  tool  would  suggest  the  time  it  would  take  to  get  to  a  desired  intercept 
location  given  a  specific  speed.  The  time  difference  between  the  time-to-target  for  the 
enemy  aircraft  and  the  intercepting  aircraft  affords  a  period  of  "slack  time"  when  the 
aircraft,  while  on  the  ground,  can  be  readied  through  a  series  of  alert  states  and  then 
scrambled  at  the  optimal  time.  Together  with  a  "position  strength  measure"  calculated 
for  each  opposing  side,  and  a  heuristic  (developed  from  a  model  of  the  NOPSO),  a 
suggested  alert  state  can  be  given  for  the  readying  and  scrambling  of  a  number  of 
intercept  aircraft  from  predefined  locations. 

The  tool  would  not  be  prescriptive,  but  merely  present  suggestions  on  when  aircraft 
could  have  their  alert  states  changed.  (By  way  of  analogy,  this  could  be  much  like  the 
"hints"  provided  to  the  user  by  a  computer  in  a  chess  game.  A  range  of  valid  and 
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suggested  moves  are  presented  as  options  to  the  user,  but  ultimately  it  is  up  to  the  user 
to  choose  which,  if  any,  of  the  moves  they  wish  to  take.)  The  tool  might  be  used 
together  with  the  Asset  Visualisation  Tool  in  proposing,  managing,  and  executing 
posture  plans,  but  whereas  that  tool  relied  solely  on  known  information  for  friendly 
aircraft,  this  tool  may  be  of  little  help  in  those  situations  where  enemy  aircraft  avoid 
being  detected  by  radar. 

Impl  ementation 

There  are  four  aspects  of  this  tool  that  require  design  and  implementation: 

■  A  graphical  user  interface  (GUI)  that  supports  the  definition  of  various,  initial 
conditions; 

■  A  suitable  equation  that  defines  an  evaluation  function  for  a  position  strength 
measure; 

■  Heuristics  for  suggested  alert  state  changes;  and 

■  An  appropriate  visualisation  for  the  display  of  results. 

Various  initial  conditions  need  to  be  specified,  including  the  numbers  and  locations  of 
available  aircraft,  their  alert  states,  and  a  number  of  points  in  space  that  define  a 
"trigger  line",  named  as  such  because  it  triggers  a  response  from  the  defenders.  This 
line  (which  might  define  the  same  region  as  the  ADIZ)  would  act  as  a  reference  for  the 
calculation  of  an  evaluation  function  that  would  provide  a  numeric  "score"  for  the 
"strength"  of  the  enemy,  and  for  the  defenders.  The  function  could  combine  a  number 
of  variables  into  the  score,  but  it  might  be  that  something  as  simple  as  the 
multiplication  of  the  number  of  aircraft  in  the  track  by  the  closest  distance  to  the  trigger 
line  could  be  summed  together  to  yield  a  useful  result.  For  the  defenders  to  achieve  an 
equal  (or  preferably,  greater)  score,  they  would  have  to  increase  the  number  of  aircraft 
positioned  close  to  the  trigger  line. 

The  application  of  various  heuristics  could  suggest  alternative  alert  states  that  would 
result  in  aircraft  being  scrambled  at  the  appropriate  time  to  yield  a  suitable  position 
strength  score.  As  previously  mentioned,  the  alert  state  changes  would  be  timed  such 
that  aircraft  would  be  scrambled  at  the  optimal  time  to  meet  the  inbound  enemy.  The 
derivation  of  alternatives  is  far  from  a  trivial  activity,  and  it  may  be  that  it  is  something 
that  only  a  human  commander  could  ever  hope  to  do  well,  but  the  "scoring"  of  a  user's 
intended  move  with  the  evaluation  function  might  enable  them  to  explore  different 
solutions  and  consider  alternative  courses  of  action  (for  example,  moving  ground- 
based  aircraft  to  a  higher  alert  versus  moving  airborne  aircraft  closer  to  the  trigger 
line). 

A  visualisation  of  the  results  of  this  tool  has  not  yet  been  envisaged.  It  may  be  that  it 
uses  a  Gantt-chart-format  like  that  of  the  AVT,  or  it  may  provide  a  written  list  of  the 
top  10  options.  At  the  very  least,  the  "slack  time"  that  a  ground-based  aircraft  has 
before  being  scrambled  could  be  shown,  as  could  the  calculated  position  strength  score 
of  the  enemy  and  the  defenders.  These  (and  other)  design  issues  will  be  left  for  further 
discussion  with  the  intended  users. 
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Information 

Information  potentially  required  to  implement  this  tool  includes  the  distance/speed  of 
approaching  enemy  and  defending  aircraft  (from  Phoenix  track  updates),  the  location 
of  the  desired  interception  area  (defined  by  user  interaction  with  the  GUI),  and  the 
number,  location,  and  alert  status  of  available  fighter  aircraft  (maintained  by  the  AVT 
and  ADOCS).  Various  "fudge  factors"  may  have  to  be  considered  to  take  account  of  the 
time  taken  to  reach  intercept  speed  from  the  initial  order  to  scramble. 

Feasibility 
■  Medium: 

This  tool  relies  on  many  types  of  information  being  available.  If,  for  various  reasons, 
the  information  is  not  available  (or  accurate)  then  the  tool  may  prove  to  be  of  little  use. 
Some  doubt  regarding  the  feasibility  of  this  tool  comes  about  because  of  the  need  to 
incorporate  some  potentially  novel  (and  as  yet,  untested)  algorithms  and  heuristics. 

Desirability 
-  High: 

This  tool  is  the  most  complex  of  those  outlined,  and  introduces  elements  of  automation 
to  the  decision  aids.  Unless  it  incorporates  well-tested  and  trusted  heuristics  used  by 
NOPSOs,  there  exists  a  strong  possibility  that  the  posture  changes  suggested  by  this 
tool  may  be  resisted  by  users.  Further  research  will  be  necessary  to  determine  an 
appropriate  level  of  automation. 


4.1.5  A  multi-attribute  track  history 
Problem 

Phoenix  users  have  a  good  appreciation  of  the  geospatial  information  concerning  the 
aircraft  under  their  watch,  but  they  have  a  problem  with  the  visibility  of  other  track 
data  that  changes  "below  the  surface"  of  the  interface,  that  is,  not  incorporated  into  and 
presented  by  the  current  visualisation.  This  information  is  not  easily  observable 
because  any  changes  are  gradual  and  subtle,  or  occur  in  time  periods  or  physical 
locations  that  are  not  being  watched.  The  current  system  can  display  this  key 
information  for  the  last  update  to  the  track,  but  to  maintain  an  appreciation  of  the 
changes  over  time  requires  a  massive  load  on  the  user's  memory.  A  tool  is  proposed 
that  logs  the  values  of  heading,  height,  and  speed  for  a  selected  number  of  tracks  over 
a  period  of  time,  and  displays  these  in  a  way  for  the  user  to  observe  the  track 
behaviour,  thereby  assisting  in  identification  of  aircraft  type  and  possible  intention.  A 
software  agent  augmentation  to  this  tool  is  presented  as  a  separate  tool  in  section  4.1.6. 

User(s) 

■  NOPSO,  TACDIR,  and  possibly  staff  of  the  RCC 
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Impact 

By  graphically  presenting  the  track  history  over  time,  the  user  is  more  likely  to  detect 
behaviour  that  would  otherwise  be  missed.  The  visualisation  would  build  on  the 
human  ability  to  see  complex  patterns,  enabling  the  NOPSO  to  perform  threat 
assessment  more  accurately,  with  a  lessened  load  on  memory.  A  display  of  the  raw, 
underlying  track  data  would  enable  the  user  to  choose  appropriate  conditions  for  the 
deviation  alert  tool  (Section  4.1.6),  and  potentially  identify  why  certain  alerts  failed  to 
be  raised  (such  as  if  the  specified  constraints  were  too  narrow).  Conversely,  the 
visualisation  may  present  too  much  clutter  to  the  user,  and  act  as  a  distraction,  when 
all  they  really  need  is  to  be  alerted  to  a  particular  change  of  interest.  (Tool  4.1.6 
addresses  this  issue.) 

Implementation 

The  tool  would  display  the  change  of  value  in  an  aircraft's  heading,  height,  or  speed  as 
a  stacked  line  chart,  much  like  a  stock  market  chart  or  computer  system  performance 
monitoring  tool.  The  user  would  be  able  to  set  the  maximum  number  of  values  to 
record  in  the  history  (for  example,  displaying  the  last  20  values  only). 

Information 

The  only  information  required  to  implement  this  tool  is  the  Phoenix  track  data  (such  as 
track  name,  heading,  height,  speed,  etc.) 

Feasibility 

■  High: 

The  aim  of  the  tool  seems  highly  achievable,  as  the  information  required  for  it  is 
automatically  available  via  a  feed  of  data  being  broadcast  around  the  Phoenix  network. 
The  tool  could  be  developed  and  tested  with  recorded  Phoenix  data. 

Desirability 

■  High: 

This  tool  aims  at  addressing  a  key  difficulty  faced  by  commanders  in  the  TAOC,  that  of 
monitoring  a  situation  over  time  and  recording  information  changes  that  can  be 
overlooked,  due  to  geospatial  visualisation  deficiencies  or  operator  inattention. 


4.1.6  Alerts  when  aircraft  deviate  from  expected  behaviour 
Problem 

The  visualisation  provided  by  the  multi-dimensional  track  history  tool  (Section  4.1.5) 
would  help  commanders  identify  track  type  and  intent,  but  it  still  relies  on  the  user 
having  the  correct  track  visualisation  showing,  noticing  odd  behaviour  in  the  chart, 
and  identifying  important  links  between  the  data  being  watched.  A  tool  is  proposed 
that  is  like  a  software  agent  acting  on  the  user's  behalf,  "watching"  the  raw  data  being 
visualised  by  the  previous  tool,  and  which  alerts  the  user  to  a  series  of  conditions  being 
met  (or  constraints  broken).  Effectively,  this  would  be  like  posing  statements  such  as  "I 
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think  this  is  a  civil  track  on  route  to  X.  Let  me  know  if  it  does  something  it  shouldn't  be 
doing,  such  as  going  off-course  more  than  10  degrees",  or  "Let  me  know  if  a  track 
suddenly  descends,  as  though  it  is  trying  to  fly  below  our  radar". 

User(s) 

■  NOPSO,  TACDIR,  and  possibly  staff  in  the  RCC 

Impact 

Having  a  software  agent  observe  the  recorded  data  could  reduce  the  workload  of  the 
user.  However,  trust  is  a  major  issue  and  this  tool  would  require  studies  to  identify  the 
number  of  constraints  that  result  in  optimal  use.  The  obvious  issue  is  that  the  number 
of  constraints  chosen  might  result  in  too  many  (or  too  few)  alerts,  directly  affecting  the 
user's  trust  in  the  tool. 

Implementation 

Constraints  could  be  entered  for  maximum,  minimum,  and  difference  values,  such  as 
maximum  and  minimum  speed,  change  in  speed,  maximum  and  minimum  height, 
change  in  height  and  change  in  heading.  Complex  constraints  might  be  built  using 
Boolean  logic  (eg.  "Alert  if  height  <  2000  and  speed  >  800").  A  library  of  aircraft  types 
might  allow  the  user  to  easily  load  complex  constraints  based  on  known  aircraft 
performance  limitations. 

Deviation  in  behaviour  might  be  indicated  via  a  track  symbol  being  coloured 
differently  and  a  small  alert  popping  up  next  to  it,  or  a  small  window  might  show  a  list 
of  currently  suspect  tracks  and  the  constraints  they  violated.  This  tool  could  be 
extended  to  watch  other  values  such  as  latitude  and  longitude,  or  a  range  of  points 
specifying  a  region  that  should  not  be  left  or  entered. 

Information 

This  tool  would  have  no  additional  information  requirements  other  than  access  to  the 
data  being  logged  by  the  multi-dimensional  track  history  tool  (such  as  heading,  height, 
speed,  latitude,  and  longitude).  The  suggested  extension,  a  library  of  aircraft  types, 
would  require  the  once  off  entering  of  typical  aircraft  performance  values. 

Feasibility 

■  High: 

Other  than  a  period  of  fine-timing  some  of  the  "watch  values"  (to  minimise  false  alerts, 
or  maximise  desired  alerts),  this  tool  is  algorithmically  very  simple  in  nature.  The 
accuracy  of  alerts  generated  using  this  tool  could  be  validated  against  known  track 
types  in  the  recorded  Phoenix  data. 

Desirability 

■  High: 

This  tool  successfully  allocates  a  task  to  the  computer  to  which  it  is  perfectly  suited:  the 
rapid  testing  of  a  large  number  of  (potentially)  complex  conditions.  The  human 
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commander  is  freed  for  complex  decision-making,  leaving  the  computer  in  charge  as  a 
"set  of  eyes"  in  a  laborious  task.  And  rather  than  implement  a  complex  and  potentially 
error-prone  algorithm  to  identify  what  a  track  is,  this  tool  offers  to  alert  the  user  to  a 
behaviour  or  situation  for  which  it  is  not. 


4.1.7  A  searchable  emitter  library  to  help  identify  aircraft 
Problem 

A  system  that  accepted  ELINT  data  of  aircraft  radar  signatures  and  IFF  "squawks" 
could  search  a  library  of  emitter  data  to  produce  a  reduced  set  of  possible  matches  to 
known  aircraft  types. 

User(s) 

■  Primary  users  would  be  in  the  RCC  (where  the  sensor  data  is  available  on  the  track 
when  identification  occurs). 

Impact 

The  speed  and  accuracy  of  determining  enemy  aircraft  type  could  be  greatly  improved. 

Implementation 

A  well-designed  graphical  interface  could  access  a  complex  database  to  allow 
searching  on  a  number  of  variables. 

Information 

This  tool  could  make  use  of  data  available  to  Phoenix  (such  as  IFF  modes),  however  it 
is  more  than  likely  that  it  would  require  access  to  the  raw  data  that  the  MV15000 
receives,  prior  to  its  fusion  and  dissemination  to  the  Phoenix  consoles.  The  software 
would  also  need  to  be  built  upon  a  database  that  is  populated  with  a  large  dataset  of 
typical  radar  signatures  and  IFF  codes. 

Feasibility 

■  Medium: 

The  ability  to  hook  into  an  MV15000  data  feed  may  prove  problematic. 

Desirability 

■  Low: 

We  expect  that  it  may  be  more  useful  to  look  for  unexpected  aircraft  behaviour  (see 
4.1.6)  but  the  relative  simplicity  of  this  tool  would  allow  a  stronger  focus  on  user- 
interface  issues.  The  research  appears  to  fall  under  the  jurisdiction  of  DSTO's 
Electronic  Warfare  Division.  In  addition  it  falls  outside  of  the  scope  of  the  task's 
TAOC-centred  domain.  Also  it  is  not  known  whether  a  real  need  exists  for  a  tool  such 
as  this,  or  indeed,  whether  a  tool  that  performs  this  task  is  already  in  use  by  the  RCC. 
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4.1.8  A  long-term  asset  scheduler  for  radar  and  aircraft  maintenance  and 
relocation 

Problem 

Tools  such  as  the  AVT  assist  commanders  in  managing  their  aircraft  over  limited 
timeframes,  typically  in  the  order  of  hours.  Longer-term  campaigns  require  a 
management  of  other  resources,  such  as  the  scheduling  of  OTHR  radar  coverage, 
movement  of  aircraft  to  the  area  of  operations,  and  cycling  of  personnel  to  duty.  An 
appreciation  of  asset  availability  and  readiness  over  the  course  of  days  and  weeks  is 
essential  for  planning  at  the  strategic  and  operational  levels,  but  might  also  assist  those 
at  the  tactical  level  in  making  more  adequately-informed  decisions. 

User(s) 

■  DNO,  NOPSO 

Impact 

A  richer  situation  awareness  could  be  achieved  at  the  operational  and  strategic  levels 
of  command. 

Implementation 

A  revisit  to  some  of  the  aspects  of  the  early  AVT  concept  might  prove  fruitful.  Initial 
intentions  were  to  display  assets  other  than  aircraft  on  the  time-based  Gantt  chart,  such 
as  the  availability  of  OTHR  radar  feeds  or  other  network  issues.  For  example, 
commanders,  on  seeing  that  OTHR  feeds  would  be  lost  for  a  period  of  time  in  the  near 
future,  might  choose  a  more  aggressive  posture  to  compensate  for  the  short  time  when 
they  would  be  operating  (relatively)  "blind".  Issues  remain  over  whether  such  a  tool 
would  enable  the  user  to  compensate  for  a  lack  of  information. 

Information 

Information  required  includes:  radar  status  and  scheduling;  aircraft  serviceability  and 
availability  (currently  maintained  on  systems  such  as  CAMM2);  and  various  others, 
depending  on  the  assets  that  would  be  modelled  and  visualised. 

Feasibility 

■  Low: 

Information  regarding  asset  maintenance  and  availability  would  only  be  known  at 
locations  outside  of  the  TAOC  (namely,  squadrons  and  radar  surveillance  units), 
suggesting  that  the  system  would  need  to  extend  far  afield.  A  huge  effort  would  be 
required  to  implement  a  tool  such  as  this,  even  though  it  might  only  be  an  extension  to 
an  existing  tool  such  as  the  AVT.  It  falls  well  outside  of  the  bounds  of  an  achievable 
concept  demonstrator,  given  various  personnel  and  time  constraints,  and  the  wider 
plans  of  this  work  to  provide  a  range  of  decision  aids. 

Desirability 

■  Low: 
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This  tool  would  be  based  on  a  known  (and  long  existing)  requirement,  and  would 
essentially  be  an  extension  to  the  current  version  of  the  Asset  Visualisation  Tool  (as 
complex  as  that  may  be).  The  scope  of  such  a  system,  from  the  NCC  down  to  the 
squadron  and  radar  surveillance  unit  levels,  indicates  a  massive  undertaking — much 
too  complex  for  the  purpose  of  a  concept  demonstrator.  (This  was  the  primary  reason 
for  the  scaling  back  of  the  AVT's  requirements.) 
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5.  Conclusions 


This  analysis  examined  issues  surrounding  specification  of  new  software  tools  for  the 
NOPSO.  Previous  work  carried  out  over  the  last  few  years,  both  descriptive  and 
predictive,  was  revisited  to  provide  background  information  on  the  NOPSO  s  tasks  in 
the  TAOC.  Cognitive  Task  Analysis  was  performed  to  determine  the  information  needs 
of  the  NOPSO  that  could  be  addressed  by  software  design. 

While  contemplating  the  development  of  software  tools  the  authors  were  mindful  of 
the  limitations  of  human  working  memory  (Baddeley,  1986).  Specifically,  when 
working  memory  is  overloaded,  the  obvious  solution  is  to  resort  to  memory  aids, 
sometimes  called  external  memory  (Newell  &  Simon,  1972),  however,  such  memory 
aids  must  themselves  not  add  to  the  workload.  Additionally,  the  appropriate  allocation 
of  tasks  to  the  computer  should  allow  the  human  user  to  focus  less  on  computationally 
intensive,  error-prone  calculations,  and  more  on  complex  decision-making  issues. 

In  contrast  to  information  overload,  having  too  little  information  will  result  in  a 
deficient  level  of  situation  awareness.  The  tools  outlined  here  have  illustrated  the 
importance  of  improving  the  visibility  of  information  that  lies  neglected  or  buried  by 
the  interface  or  inappropriate  visualisation.  A  clear  example  is  that  of  detecting  a 
change  in  speed  or  altitude  by  a  given  track.  The  typical  geospatial  display  focuses  on 
latitude  and  longitude  information,  but  fails  to  present  information  regarding  speed  or 
altitude  in  a  meaningful  way.  This  is  a  visualisation  of  information  that  a  large  number 
of  people  have  access  to,  but  that  no  one  can  see.  There  is  little  hope  in  detecting  a 
momentary  (though  possibly,  significant)  event  in  a  "cloud"  of  tracks. 

The  computer  can  support  the  user  in  a  range  of  tedious  monitoring  and  recording 
functions,  such  as  notifying  the  user  to  conditions  they  should  be  mindful  of,  or 
updating  time-based  information  with  the  passage  of  time.  Compare  this  with  the 
pursuit  of  card  counting"  in  a  casino:  though  not  necessarily  a  complex  task  in  itself,  it 
tends  to  be  near-impossible  for  most  people  (without  the  aid  of  recording  tools) — the 
player  who  has  an  ability  to  do  this  gains  a  definite  edge.  The  analogy  to  be  drawn  is 
that  the  user  does  not  necessarily  require  a  fully  automated  tool,  but  could  easily  be 
assisted  in  areas  in  which  they  either  struggle,  or  which  consume  too  much  time, 
taking  their  concentration  from  tasks  that  only  they  can  perform. 

The  Battle  Management  tools  outlined  in  this  document  aim  to  support  the  user  in  a 
range  of  cognitive  areas,  and  are  all  achievable  with  current  technology.  They  could 
form  part  of  a  more  ambitious  technological  goal  of  an  interactive,  automated  planner, 
but  stand  equally  well  on  their  own  as  simple,  individual  decision  aids.  It  is  envisaged 
that  these  tools  would  be  operated  in  a  stand-alone  mode,  receiving  live  Phoenix  track 
data  from  a  network,  without  having  to  be  installed  on  existing  hardware,  and 
consequently,  not  impacting  on  current  operations. 
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In  this  final  section  we  have  tabulated  the  author-assigned  priority  of  each  tool 
concept,  based  on  the  identified  need  and  the  assessed  feasibility  of  development. 
Based  on  this,  OPSOs  from  various  countries  will  give  their  opinions  on  interface 
designs  for  the  first  six  tools.  For  the  development  and  evaluation  of  software 
prototypes  the  RAAF,  in  particular  the  SCG,  must  delegate  resources. 


Table  1:  Summary  of  feasibility /desirability  assessments  to  determine  tools  worth  pursuing. 


Tool 

Feasibility 

Desirability 

Investigate 

A  time-to-target  display 

High 

High 

V 

A  multi-dimensional  track  history 

High 

High 

S 

Alerts  when  aircraft  deviate  from  expected 
behaviour 

High 

High 

V 

An  estimation  of  aircraft  travel  when  lost  from 
radar 

Medium 

High 

V 

An  estimation  of  enemy  fuel/ remaining  range 

Medium 

High 

S 

An  estimation  of  the  latest  possible  scramble 
time  for  aircraft 

Medium 

High 

S 

A  searchable  emitter  library  to  help  identify 
aircraft 

Medium 

Low 

X 

A  long-term  asset  schedular  for  radar  and 
aircraft  maintenance  and  relocation 

Low 

Low 

X 
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114MCRU 

1RSU 

2CRU 

3CRU 

41 WG 

ADIZ 

ADOCS 

AIRCON 

AVT 

CAP 

CCC 

CTA 

DCA 

DNO 

FC 

GUI 

HQAC 

JFAOC 

MV15000 

NCC 

NOPSO 

NORTHROC 

OCA 

PDS 

RAAF 

RCC 

ROE 

RSO 

SACTU 

SADOC 

SCG 

SME 

SOP 

TAAATS 

TACDIR 

TAOC 

TDRAP 

WASP 


Appendix  A:  Abbreviations 

No  114  Mobile  Control  and  Reporting  Unit 
No  1  Radar  Surveillance  Unit 
No  2  Control  and  Reporting  Unit 
No  3  Control  and  Reporting  Unit 
41  Wing 

Air  Defence  Identification  Zone 

Air  Defence  Operations  Computer  System 

Air  Controller 

Asset  Visualisation  Tool 

Combat  Air  Patrol 

Command  &  Control  Centre 

Cognitive  Task  Analysis 

Defensive  Counter  Air 

Director  of  NORTHROC  Operations 

Fighter  Controller 

Graphical  User  Interface 

Headquarters  Air  Command 

Joint  Force  Air  Operations  Centre 

(Computer  system  underlying  Phoenix  displays) 

Northern  Command  Centre 

NORTHROC  Operations  Officer 

NORTHem  Region  Operations  Centre 

Offensive  Counter  Air 

Phoenix  Display  System 

Royal  Australian  Air  Force 

Regional  Correlation  Centre 

Rules  Of  Engagement 

Regional  Surveillance  Officer 

Surveillance  And  Control  Training  Unit 

Sector  Air  Defence  Operations  Centre 

Surveillance  and  Control  Group 

Subject  Matter  Expert 

Standard  Operating  Procedures 

The  Australian  Advanced  Air  Traffic  System 

Tactical  Director 

Tactical  Air  Operations  Centre 

Technology  Demonstrator  Recognised  Air  Picture 

Wide  Area  Surveillance  Picture 
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Appendix  B:  List  of  interviewees 


Name 

Cat 

Organisation 

SQNLDR  Steve  Borbiro 

AIRDEF 

DSCA 

SQNLDR  Peter  Cooper 

AIRDEF 

114MCRU 

SQNLDR  Tracey  Friend 

AIRDEF 

2CRU 

SQNLDR  Richard  Pizzuto 

AIRDEF 

41WG 

SQNLDR  Krista  Thompson 

AIRDEF 

SACTU 

WGCDR  Daryl  Eggins 

AIRDEF 

41WG 

WGCDR  Daryl  Hunter 

AIRDEF 

1RSU 

WGCDR  Graham  King 

AIRDEF 

2CRU 

WGCDR  Ken  Watson 

AIRDEF 

3CRU 

Table  2:  List  of  Interviewees 
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